amd/virt_ssbd: set SSBD at vCPU context switch
authorRoger Pau Monne <roger.pau@citrix.com>
Tue, 15 Nov 2022 13:26:55 +0000 (14:26 +0100)
committerAndrew Cooper <andrew.cooper3@citrix.com>
Wed, 16 Nov 2022 00:18:42 +0000 (00:18 +0000)
commitb2030e6730a2b727dbfa7ecc5b9f1deb5f50d3fb
tree14959ec179e0d732f0c2ac37f1661953a63941b6
parentaa717d803eb5442c0ab9c6f078b6ff2078092bae
amd/virt_ssbd: set SSBD at vCPU context switch

This fixes an issue with running C code in a GIF=0 region, that's
problematic when using UBSAN or other instrumentation techniques.

The current logic for AMD SSBD context switches it on every
vm{entry,exit} if the Xen and guest selections don't match.  This is
expensive when not using SPEC_CTRL, and hence should be avoided as
much as possible.

When SSBD is not being set from SPEC_CTRL on AMD don't context switch
at vm{entry,exit} and instead only context switch SSBD when switching
vCPUs.  This has the side effect of running Xen code with the guest
selection of SSBD, the documentation is updated to note this behavior.
Also note that then when `ssbd` is selected on the command line guest
SSBD selection will not have an effect, and the hypervisor will run
with SSBD unconditionally enabled when not using SPEC_CTRL itself.

As a result of no longer running the code to set SSBD in a GIF=0
region the locking of amd_set_legacy_ssbd() can be done using normal
spinlocks, and some more checks can be added to assure it works as
intended.

Finally it's also worth noticing that since the guest SSBD selection
is no longer set on vmentry the VIRT_SPEC_MSR handling needs to
propagate the value to the hardware as part of handling the wrmsr.

Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Extend the msrs->virt_spec_ctrl context switching comment.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
docs/misc/xen-command-line.pandoc
xen/arch/x86/cpu/amd.c
xen/arch/x86/hvm/svm/entry.S
xen/arch/x86/hvm/svm/svm.c
xen/arch/x86/include/asm/msr.h
xen/arch/x86/msr.c